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W hen i talk about how to use different sorts of 
objects, people often ask me what these objects 
look like. I draw a bunch of bubbles and arrows, 
underline things while I'm talking, and (hopefully) peo¬ 
ple nod knowingly. The bubbles are the objects I’m talk¬ 
ing about, and the arrows are the pertinent relationships 
between them. But of course the diagram is not just cir¬ 
cles and lines; everything has labels to identify them. The 
labels for the arrows are easy: The name of the method i n 
the source that returns the target. But the labels for the 
bubbles are not so obvious. It's a label that somehow 
describes the object and tells you which one it is. We all 
know how to label objects in this way, but what is it that 
we’re doing? 

This is a Smal Italk programmer’s first brush with a big¬ 
ger issue: How do you display an object as a string?Turns 
out this is not a very simple issue. Visual Works gives you 
four different ways to display an object as a string: 
printstring, displaystring,TypeConverter, and PrintConverter. 
Why does there need to be more than one way? Which 
option do you use when? 

This article is in two parts. This month, I'll talk about 
printstring and displaystring. In September, I'll talk about 
TypeConverter and PrintConverter. 

printstring AND displaystring 

There are two messages you can send to an object to dis¬ 
play it as a string: 

• printstring—Displays the object the way the 
developer wants to see it. 

• displaystring—Displaystheobjectthe way theuser 
wants to see it. 

printstring is as old as Smalltalk itself. It was part of the 
original Smalltalk-80 standard and was probably in 
Smalltalk long before that. It is an essential part of how 
I nspector is implemented, an inspector being a develop¬ 
ment tool that can open a window to display any object. 
An inspector shows all of an object's slots (its named and 
indexed instance variables); when you select one, it 
shows that slot's value as a string by sending the slot’s 


value the message printstring. The inspector also shows 
another slot, the pseudovariable self. When you select 
that slot, the inspector displays the object it's inspecting 
by sending it printstring. 

displaystring was introduced in VisualWorks 1.0, more 
than 10 years after printstring, displaystring isan essential 
part of how SequenceView (VisualWorks’ List widget) is 
implemented. The list widget displays its items by dis¬ 
playing a string for each item. The purpose of this dis¬ 
play-string is very similar to that of the print-string, but 
the results are often different. 

printstring describes an object to a Smalltalk program¬ 
mer. To a programmer, one of an object's most important 
properties is its class. Thus a print-string either names 
the object’s class explicitly (a VisualLauncher, Ordered- 
Collection (#a #b), etc.) or the class isimplied (#pri ntStri ng 
isa Symbol, 1/2 isa Fraction, etc.). Theuser, on the other 
hand, couldn't care less what an object’s class is. Because 
most users don't know 00, telling them that this is an 
object and what its class is would just confuse them. The 
user wants to know the name of the object, displaystring 
describes the object to the user by printing the object's 
name (although what constitutes an object’s "name" is 
open to interpretation). 

STANDARD IMPLEMENTATION 

The first thing to understand about printstring is that it 
doesn't do much; its companion method, printOn:, does 
all of the work. This makes printstring more efficient 
because it uses a stream for concatenation. 1 Here are the 
basic implementors in VisualWorks: 

Obj ect »p ri n t St ri n g 
| aStream | 

aStream : = WriteStream on: (String new: 16). 
self printOn: aStream. 

^Stream contents 

Object»printOn: aStream 
| title | 

title :=self class name. 
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nextPutAII:' '.self name] 


aStream nextPutAII: ((title at: 1) isVowel 
ifTrue: ['an '] ifFalse: ['a']). 
aStream print: self class 

displaystring is not implemented 

as gracefully as printstring. Rather than using a two-step 
process and 

a stream, displaystring is a single method that returns a 
string. By default, that string isthe object’s print-string: 

Obj ect»d i spl ayStri n g 
''self printstring 

Ideally, displaystring should be implemented using 
displayOn:, but that message already has a different 
meaning in the VisualComponent hierarchy. However, 
those methods in the VisualComponent hierarchy would 
be better named "displayWith:," which more accurately 
describes what the method does. This would then free 
up displayOn: to be implemented to add an object’s 
name onto a stream. Until displaystring is imple¬ 
mented this way, subimplement displaystring in your 
own classes. 

displaystring is a VisualWorks convention that the 
other Smalltalk dialects do not have. However, as you 
can see, its implementation is very simply so you can 
easily add it to your VisualSmalltalk or IBM Smalltalk 
image if you'd I ike to. 

YOUR IMPLEMENTORS 

You should never implement printstring in your own class 
(even though ParcPI ace did i n H el pPage and H el pSeeAlso). 
However, you wi 11 often want to enhance the stri ng it pro¬ 
duces; do so by subimplementing printOn:. 

Your implementors of printstring should always speci¬ 
fy the object’s cl ass. Furthermore, itshould tell the devel¬ 
oper which instance of that class it is. To do this, print- 
String (implemented in printOn:) should printout one or 
more of the object’s identity variables. Identity variables 
are one of the types of instance variables I described in 
my previous article. 2 The values in an object’s identity 
variables identify which instance it is and rarely change. 
They are the keys used to find that object in a dictionary 
or a database. By printing the identity variables, you’re 
tel ling the developer which instance this is Ifhe wants to 
see its status and cache variables, he can use an inspec¬ 
tor. If printOn: needs to print out a variable that’s not 
a string, it should send that variable printstring or 
displaystring. 

Cursor has a good example of printOn:. A Cursor has a 


Basically, the cursor prints its class and its name (sepa¬ 
rated by a space). That tells the developer this is a Cursor 
and which one it is. 

Your implementors of displaystring should never speci¬ 
fy what the object’s class is, but they should specify which 
instance it is. displaystring does this by printing one or 
more of the object’s identity variables M any objects don't 
have any identity variables In these cases, there probably 
is no good way to display thisobject to the user. In such a 
case; just inherit Object»displayString and avoid using it. 

Remember that printstring is how you want this object 
to appear in an inspector to a developer; displaystring is 
how you want it to appear in a list widget to a user. 

AN EXAMPLE 

Let's say you’re implementing the class Person. It has an 
aspect, name, which is an instance of PersonName. The 
classes will be subclassed from Object. This means that 
their print- and display-strings will be "a Person" and "a 
PersonName."Thisisof limited usein an inspector; worse, 
a selection-in-list for a collection of Persons will list "a 
Person" in every slot. 

Here’s how we could implement printstring (via 
printOn:) and displaystring to make them more useful: 

Perso n »pri ntOn: aWriteStream 
super printOn: aWriteStream. 
aWriteStream 
nextPutAII: ': 

nextPutAII: self displaystring 

Perso n »d i spl ayStri n g 
^self name displaystring 

PersonName»printOn: aWriteStream 
super printOn: aWriteStream. 
aWriteStream 
nextPutAII: ': 

nextPutAII: self displaystring 

PersonName»displayString 

''self lastName,',', self firstName 

The results for a person named "John Smith" are shown 
i n Table 1. 

Note that i mplementi ng pri n tStri ng to send the message 
displaystring is somewhat unusual. However, I find itto be 
asimpleandconvenientexampleofreuseformanyobjects. 


name aspect to identify which cur¬ 


sor it is. Thus its printOn: method 
looks I ike this: 

Cursor»printOn: aStream 
self name = nil 
ifTrue: [...] 
ifFalse: [aStream 
print: self class; 


Method 

Default Output String 

Custom Output String 

Perso n »pri n tStri n g 

a Person 

a Person: Smith, J ohn 

Person»displayString 

a Person 

Smith, J ohn 

Perso n N ame»pri n tStri n g 

a PersonName 

a PersonName: Smith, J ohn 

PersonName»displayString 

a PersonName 

Smith, J ohn 


Table 1.The strings produced by printstring and displaystring. 
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| DISPLAY AN OBJECT AS A STRING _ 

'aStream contents 


This can have adverse consequences in ENVY since 
Object»printString and Object»displayString are defined 
in separate applications, Kernel and WindowSystem, re¬ 
spectively. Thus in ENVY, your applications that con¬ 
tain implementors of printstring that use displaystring 
may need to have WindowSystem—and thus Kernel as 
well—as prerequisites. Specifically, the implementors of 
displaystring that printstring uses must be in the prerequi¬ 
sites; luckily, Object»displayString is usually not one of 
them. Setting up the prerequisites is usually not a prob¬ 
lem for Application Model applications, but can be a 
problem for Domain Model applications, because they 
should not have WindowSystem as a prerequisite. If this is 
a problem for your code, the sol uti on i s to modify the OTI 
applications to move the necessary implementors of 
displaystring from WindowSystem to Kernel. (Or you can 
ignore the problem because you probably won’t use the 
image without a windowing system anyway!) 

printstring SHOULD NOT FAIL 

Sometimes printstring fails and issues an error notifier. 
This is really annoying. Often during development, you 
have an object thatisnotworkingcorrectly. As you inspect 
it to figure out why, you keep getti ng message- not-under- 
stood errors saying that UndefinedObject does not under¬ 
stand some message. This really limits the usefulness of 
the inspector! 

One way to get around this problem is to have your 
implementors of printOn: check each variable before 
using it. Only print out a variable if it's not nil. However, 
checkingfornil all of the time is tedious. Even if the vari¬ 
able is not nil, it may still be of the wrong type (which 
would explain why the object is not working correctly). 
But since the variable’s value is the wrong type, it proba¬ 
bly won’t understand the messages print On: sends to it, so 
printOn: will still fail. 

Another tactic is to only send the variables messages 
that all objects understand. If you only send messages 
I ike printstring to a variable, the message is guaranteed to 
work no matter what the variable's value is. However, if 
your implementor of printOn: contains a bug, it will fail 
and fixing the bug wi 11 be frustrating. 

The universal way to prevent printstring from failing is 
to have it trap errors and handle them. You can trap all 
errors by implementing pri ntStri ng I ike this: 

Obj ect»pri n tStri n g 
| aStream | 

aStream :=WriteStream on: (String new: 16). 

Object errorSignal 
handle: 

[:ex | 
aStream 
reset; 

nextPutAII: 'an invalid 
print: self class. 

ex return] 

do: [self printOn: aStream], 


This way, if printOn: fails, the error handler will print out 
thenameoftheclass and say that the instance is invalid. At 
th i s poi nt, you can i nspect theobj ect to see why it i s i nval id. 

I thinkthat is a lot better than getting an error notifier. 

You may wantto makethismodification in your image 
This will require modifying ParcPIace's Object»printString 
method. You should usually avoid modifying vendor 
code, but in this case I think doing so is the best solution. 

displaystring AND asString 

A common problem with using strings is that string 
concatenation (implemented in VisualWorks by 
SequenceableCollection»,) is not very polymorphic (nor 
should it be). If the concatenation argument is nil, a 
Character, an Exception, or some other nonstring-like 
object, Smalltalk will issue an error. To avoid this prob¬ 
lem, developers routinely send an object printstring 
before concatenating it. But printstring does a lousyjobof 
printing the object for concatenation: strings have 
quotes around them, symbols have pound-signs in front 
of them, most objects are cal led "an Object," etc. 

To do a better job of printing an object out so that it 
can be concatenated onto a string, many developers use 
asString. They implement Object»asString to define the 
standard protocol, then implementasString in all kinds of 
classes as they find objects that don't convert "correctly." 
I contend that this is a haphazard way to program and 
overloads ParcPIace's original asString protocol. asString is 
a message VisualWorks uses for converting a string-like 
object (such as a symbol, text, or filename) into a String. 
If an object is not at all string-like, it really has no clear 
implementation for asString. 

Instead, I thinkthatdisplayString isthesolution devel- 
opersarelookingfor. Both asString and displayString return 
strings Neither message puts any junk in the string to 
specify the object’s class. The main difference is that 
asSt ri n g i s an "as..." message Th i s i mpl i esthatthe receiver 
can be (and will be) converted to a String equivalent, 
displaystring makes no such promises of equivalency; it 
simply says it will display the object as a string that 
describes theobject. 

Thusl recommend implementingdisplayString for any 
object you need to concatenate onto a string. Implemen¬ 
tors you might need are: 

•UndefinedObject»displayString should return an empty 
string; 

•Character»displayString should return a one-character 
string; 

•CharacterArray»displayString should be reimplemented 
as " ''self asStri ng d i spl ayStri ng." 

I think this policy will be more consistent and easier to 
reuse than random implementors of asString. 

CONCLUSIONS 

H ere are the mai n poi nts i n th i s arti cl e: 

•printstring displays an object the wayadeveloper would 
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describe it. It specifies the object’s class and specifies 
which instance the object is by displaying one or more 
of i ts i denti ty vari ab I es 

•displaystring displays an object the way a user would 
descri be it. 11 does not specify the obj ect’s cl ass because 
users never do. It specifiestheobject’s name that being 
one or more of its identity variables 

•In VisualWorks, don’t subimplement printstring; sub¬ 
implement printOn: instead. Do subimplement 
displaystring. 

•Consider reimplementing Object»printString with an 
error handler so that it cannot fail. 

•Do not implement Object»asString or most other im¬ 
plementors of asString. UsedisplayString instead. 

In the next article, I'll talk about TypeConverter and 

PrintConverter. M 
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